fix(runtime): cancel standalone runs on process signals - #80

Four mediums, two of which this branch introduced in the previous commit.

- The interactive/one-shot divergence on OperationCanceledException is now
  documented instead of excused. A one-shot run reserves Cancelled for the
  caller's own token; an interactive session treats every OCE escaping a command
  as an abort, Ctrl+C and a self-cancelling handler alike. The enum doc claimed
  the loop "cannot tell who asked to stop" — false, commandCts.IsCancellationRequested
  is in scope — and claimed Cancelled covers an abandoned prompt, which emits an
  aborted mark carrying no code. Behaviour deliberately unchanged; the three mark
  tests now say they exercise a self-raising handler rather than Ctrl+C, which no
  test actually simulates.
- The swallow contract on TryWriteCommandEndAsync named the exit-code table and
  ExitCodes.Resolver, neither of which it can reach: it takes an already-resolved
  int? and both call sites pass null. Restored to the mark-write wording, and the
  parallel rule at the resolve call site loses its third restatement.
- A hosted-lifecycle diagnostic printed only the coordinator's wrapper message,
  which names the failing service and not the reason. HostedServiceLifecycleException
  always carries an inner exception, so both diagnostics now name it as
  {Type}: {Message}, the shape TryWriteResolverDiagnostic already uses.
- The pre-cancellation check in RunAsync(args, IReplHost, IServiceProvider, ...)
  moved inside the session scope, still ahead of the overlay that resolves the
  caller's factories, so a resolver and its diagnostic reach the host's writers
  rather than Console.Error.

ExitCodes.Interrupted and the Interrupted kind are now documented as inert: no
public API produces that kind, so the entry does nothing until in-framework signal
handling (#80) lands. Four lenses raised it independently; the append-only enum
promise is why the member stays rather than being dropped.

Also: the unknown-output-format refusal moves to stderr, which is the rule this
branch introduced for framework diagnostics and the last site still writing into
the data channel; ClassifyResult builds its Success outcomes through the factory
set rather than the positional constructor; the TryStopHostedServicesAsync summary
no longer claims a suppressed *outcome* travels — only a suppressed exception does,
a returned outcome is replaced; ReplExecutionOutcome.Result stops promising the
carried refusal was rendered; the duplicate token-guard bullet and three
intra-branch "previously" claims are out of the CHANGELOG; best-practices notes
that HandlerError, HandlerException and FrameworkError all default to 1.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Every run that reaches the core pipeline now ends in a ReplExecutionOutcome
(ReplExecutionOutcomeKind: Success, Help, UsageError, BindingError,
HandlerError, HandlerExitCode, HandlerException, Cancelled, Interrupted,
FrameworkError). The kind is mapped to an integer once, at the top of
CoreReplApp.ExecuteCoreAsync, through the new ReplOptions.ExitCodes table
(ExitCodeOptions) and then handed to the optional ExitCodes.Resolver hook.

Default codes change: framework refusals (unknown command, ambiguous prefix,
invalid or colliding option, context validation, unknown output format,
ambient misuse) and binding failures exit 2 instead of 1; handler failures
stay 1, help and success stay 0; Results.Exit keeps its code verbatim.
ExitCodes.Cancelled (int?, unset by default) turns a caller-token
cancellation into an exit code instead of letting the exception escape.

ReplExecutionContext.Result exposes the handler return value to middleware,
readable and replaceable after next(); ReplNext and Use are unchanged.

The interactive loop resolves shell-integration mark codes through the same
table and resolver, including Ctrl+C (conventional 130 unless remapped).
MCP sub-invocations keep the built-in defaults and skip the resolver.
Repl.Testing still raises TimeoutException when the app under test maps
Cancelled. Interrupted is reserved for the process-signal bridge (yllibed#79/yllibed#80).

Closes yllibed#81.

The file arrived as a side effect of a feature PR (fde24c4, the hidden-option
work) rather than as a release-process decision, and nothing consumes it: no
workflow, no script, no packaging step, and no document links to it.

Meanwhile CI already publishes what it was trying to be. The release job runs
`gh release create "v${VERSION}" --generate-notes`, so every published version
gets notes generated from the merged pull requests and anchored to the version a
consumer installs. The file could never be anchored that way — its own header said
so, because Nerdbank.GitVersioning assigns the version at pack time — and a review
lens correctly flagged that a breaking change pinned to "the commit closing issue

It was also the single point of conflict between concurrent pull requests, which
is how the question came up: it was the only conflicting file when #85 merged and
again when #80 rebased, with three more PRs open behind them.

The one piece of guidance that lived only here is migrated: the recipe for
restoring the pre-policy exit codes, with its test-suite and MCP consequences, now
sits in docs/configuration-reference.md beside the table it talks about. The rest
was already covered by the topic pages — docs/commands.md:172 for the additive
`isHidden` export fields, docs/testing-toolkit.md for CommandExecution.ExitCode.

docs/publishing.md now states where release notes come from and what that asks of
a PR description, so the next person does not recreate the file.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Rebased onto the merged #80, which had added three CHANGELOG sections after this
branch was written. Taking the deletion is right — nothing reads the file and the
release job generates versioned notes — but deleting it unaudited would have lost
what only it recorded, which is the mistake the review caught on this PR the first
time.

#80 documented its rule well: docs/configuration-reference.md already covers the
run-scoped token, the mode table, the epoch machine and the platform matrix. What
lived only in the changelog was the *migration consequence* for an existing app,
so that moves next to the rule it belongs to:

- taking signal ownership by default under UseCliProfile/UseDefaultInteractive, and
  that ProcessSignalHandlingMode.None restores the previous behaviour;
- interruption now resolving to 130/143 where OS-default termination used to apply,
  and what that does to a script treating any non-zero code as failure;
- the handler-token change and how it fails — ObjectDisposedException from Register
  or WaitHandle, and IsCancellationRequested silently continuing to report false,
  which the existing "must not retain it" sentence did not say.

That last one is the reason this audit was worth doing rather than assumed: a rule
tells a reader what to do, and only the consequence tells them what breaks if they
did not.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The file arrived as a side effect of a feature PR (fde24c4, the hidden-option
work) rather than as a release-process decision, and nothing consumes it: no
workflow, no script, no packaging step, and no document links to it.

Meanwhile CI already publishes what it was trying to be. The release job runs
`gh release create "v${VERSION}" --generate-notes`, so every published version
gets notes generated from the merged pull requests and anchored to the version a
consumer installs. The file could never be anchored that way — its own header said
so, because Nerdbank.GitVersioning assigns the version at pack time — and a review
lens correctly flagged that a breaking change pinned to "the commit closing issue

It was also the single point of conflict between concurrent pull requests, which
is how the question came up: it was the only conflicting file when #85 merged and
again when #80 rebased, with three more PRs open behind them.

The one piece of guidance that lived only here is migrated: the recipe for
restoring the pre-policy exit codes, with its test-suite and MCP consequences, now
sits in docs/configuration-reference.md beside the table it talks about. The rest
was already covered by the topic pages — docs/commands.md:172 for the additive
`isHidden` export fields, docs/testing-toolkit.md for CommandExecution.ExitCode.

docs/publishing.md now states where release notes come from and what that asks of
a PR description, so the next person does not recreate the file.

Rebased onto the merged #80, which had added three CHANGELOG sections after this
branch was written. Taking the deletion is right — nothing reads the file and the
release job generates versioned notes — but deleting it unaudited would have lost
what only it recorded, which is the mistake the review caught on this PR the first
time.

#80 documented its rule well: docs/configuration-reference.md already covers the
run-scoped token, the mode table, the epoch machine and the platform matrix. What
lived only in the changelog was the *migration consequence* for an existing app,
so that moves next to the rule it belongs to:

- taking signal ownership by default under UseCliProfile/UseDefaultInteractive, and
  that ProcessSignalHandlingMode.None restores the previous behaviour;
- interruption now resolving to 130/143 where OS-default termination used to apply,
  and what that does to a script treating any non-zero code as failure;
- the handler-token change and how it fails — ObjectDisposedException from Register
  or WaitHandle, and IsCancellationRequested silently continuing to report false,
  which the existing "must not retain it" sentence did not say.

That last one is the reason this audit was worth doing rather than assumed: a rule
tells a reader what to do, and only the consequence tells them what breaks if they
did not.

The servicing flow said "merge or cherry-pick the fix and commit it", and the release-notes section
said `--generate-notes` builds the body from merged pull requests. Both are true, and together they
describe a patch release that says nothing: a cherry-pick reaches the branch outside a pull request,
so it contributes no entry, and this branch is the one that deleted CHANGELOG.md.

Measured rather than assumed. `POST /releases/generate-notes` for the twelve commits between
v0.12.0-dev.45 and this branch head — real commits, no merged pull request, since #88 is still open —
returns a body of one line, the compare link, with no `What's Changed` heading at all. The same call
across a range containing #80 returns its title, author and link.

So the servicing section now asks for a pull request targeting the release branch and says why, with
editing the release body by hand as the fallback when a fix lands as a direct commit; the workflow
passes `--generate-notes` unconditionally and cannot supply notes for that path. The release-notes
section states the empty case alongside what it already said about PR descriptions.